The present disclosure relates in general to client-server architectures and devices. More specifically, the present disclosure relates to systems and methodologies for improving the provisioning and life cycle management of client-server architectures and devices.
A client-server architecture is a network architecture in which each computer or process on the network is either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives, printers or network traffic. Clients are typically personal computers (PCs) or workstations on which users run software programs/applications. Clients typically rely on servers for resources, such as files, devices and even processing power.
As used in the present disclosure, the term architecture is not simply a description of the computer system hardware. Instead, architecture refers to the portions of a computer system that a software program running on the system in effect “sees.” Thus, architecture refers to things like memory addresses, registers, instructions, condition codes and the like. In other words, a computer system architecture may be thought of as the various “states” of the computer system that a software program can manipulate.
There are two main types of configurations for client-server architectures, applications and/or hardware. In the first type of configuration, which is referred to herein as a server-centric (SC) configuration, all intelligence is resident with the server, and all operations are triggered by the server. Examples of a SC configuration include older generation client-server architectures such as the tivoli provisioning manager (TPM) or the tivoli configuration manager (TCM). In the second type of configuration, which is referred to herein as a client-centric (CC) configuration, significant portions of the server intelligence are shifted to the client, and also significant portions of the system's operations are triggered by the client. Examples of a CC configuration include new generation client-server architectures such as the IBM endpoint manager (IEM).
In a typical SC configuration, an operator/user starts a task from the server. Tasks are any operation/instruction or sequence of operations/instructions capable of being executed by a client. The task is sent to and executed on the client, and the results are sent back to the server. A disadvantage of this technique is that the client status information evaluated at the server before starting a task could be old due to the time delay between when client status information is evaluated at the server and when the related task is executed on the client. In an attempt to overcome this disadvantage, more recent SC configurations execute tasks according to a schedule, and the resulting time delay is proportional to the frequency of the schedule. For example, hardware and software inventory scans are executed in order to retrieve information about the status of the client. Usually, these scans are scheduled in order to provide information that is as accurate as possible. The information is stored in the server database. When a task is sent from the server it is only sent to those clients that match the applicability condition of the task. The matching is accomplished by looking at the server database. However, the information on in the server database might not be accurate because it is possible that something has changed since the last inventory scan. Thus, scans must be scheduled at a frequency that provides the desired level of system performance. For example, it may provide an acceptable level of system performance to conduct hardware scans weekly, while software scans may need to be conducted daily.
In a typical CC configuration, significant portions of the server intelligence are shifted to the client. These intelligent clients receive from the server the instructions of a task, and the intelligent client runs the task whenever it is needed based on a so-called applicability statement that is continuously checked. This improves the accuracy of client status information on the server. However, there is still the need to wait for the applicability condition to be sent and executed on the client, which is referred to herein as operational time. These operational times, however, depend on many factors such as the efficiency of the client and the size of the client-server environment. Accordingly, the net effect is that even in a CC configuration, operational times contribute to the time it takes to complete a task.
In some cases, even operational time delays can result in an unacceptable level of performance. For example, when an operator is running a demonstration before an audience, any perceptible delays can reflect negatively on the demonstration. Moreover, in a typical CC configuration, all operations pass through the client despite the fact that for some tasks the information already available on the server is accurate enough to provide an acceptable level of performance.
Accordingly, it would be beneficial to provide systems and methodologies for dynamically matching the level of performance/service in a client-server architecture to a given task.